The present invention relates generally to electronic circuit testing, and more particularly to a method and system for verifying the reliability of an integrated circuit device test using test simulation and integrated circuit device sin with simulated integrated circuit flaws representative of known integrated circuit defects.
The increasing reliance upon computer systems in every industrial and economic sector has led to the continuous improvement of the system hardware and associated processes that run on the hardware. While smaller processes, increased density, and faster speeds of integrated circuits have revolutionized the size and capability of today's computerized products, these same integrated circuit improvements have dramatically increased the cost and complexities of designing and testing such devices.
Currently, integrated multi-functional Electronic Automation Design (EAD) tools are used to design and simulate integrated circuit devices. The design of an integrated circuit device involves synthesizing device components to meet the device specification, which includes requirements for both device functionality and device timing. The design is typically verified against the device specification via simulation. A simulator, typically integrated into the EAD tool, simulates the operation of the design by applying a set of input stimulus to the synthesized design, and receiving and monitoring a set of simulated output responses. The input stimuli are designed to test the functionality and timing of the design against the requirements of the device specification. The simulator compares the simulated output responses to expected output response values to verify operation of the design. Once a design is satisfactorily verified against the device specification, a physical implementation of the device (e.g., a “prototype”) is generated and tested using the simulation test data, including respective pairs of input stimulus and expected output response to verify expected operation of the physical device against the design.
Simulator tools generally output simulation test data, including respective pairs of input stimulus and expected output response, to files formatted according to what is known in the industry as “event-based” data formats. Examples of event-based data formats include the IEEE Standard 1364-2001 Verilog Change Dump (VCD) format, or the IEEE Standard 1450-1999 Standard Test Interface Language (STIL) format. A VCD event-based data file, for example, typically contains header information, variable definitions (e.g., pin number or name definitions), and the timescale used. Next, the file typically contains definitions of the scope and type of variables being dumped, followed by the actual value changes at each simulation time increment. Only the variables that change value during a time increment are listed.
In contrast, the integrated circuit device testers, such as large complex industrial Automated Test Equipment (ATE), typically require input test data formatted according to a “cycle-based” data format. A cycle-based data format generally includes a set of vectors and a set of waveforms defined by a fixed device cycle time.
The event-based and cycle-based data file formats are incompatible. Accordingly, in order to utilize the simulation test data generated by the simulator to verify operation of the prototype, or to verify operation of manufactured devices during production, the event-based simulation test data must be converted to cycle-based test data compatible with the particular ATE that will test the physical device.
A translator tool typically performs the conversion of event-based simulation test data to cycle-based test data appropriate to the particular ATE testing the prototype or device under test (DUT). During the design process, the designer assumes an ideal testbench (i.e., that the tester simulation is ideal). However, because the tester simulator tester simulator can only model or approximate the behavior of the actual tester. Accordingly, when the real (actual physical) tester executes the simulation test data on the physical device under test, the test may behave differently than it did during simulation. In addition, because the event-based data must be cyclized by the translator tool, the test undergoes a translation from one test data format to another. However, in general, when any form of translation is performed on a test, a potential exists of materially changing the test. Accordingly, a test that operated correctly during simulation may not necessarily operate correctly when executed on the actual tester. This may generate misleading results. For example, if a test that properly passed simulated integrated circuit devices during simulation fails a physical embodiment of the integrated circuit device on the actual tester, the device may not necessarily be flawed; it may have been failed because the test itself is flawed, either due to translation problems or to flaws in the tester simulator used in the design of the integrated circuit.
In the production environment, time is of the essence. In terms of time-to-market, waiting for fabrication of a physical embodiment of the integrated circuit device (often referred to as waiting for “first silicon” or a later version of “silicon”) can be wasteful. In addition, because tester time is expensive and once silicon arrives, it is highly desirable to begin testing right away without having to simultaneously debug the test.
Accordingly, a process called “resimulation” or “virtual test” is often performed prior to the arrival of the physical embodiment of the integrated circuit device in order to test and debug the test. Resimulation attempts to detect flaws in the test itself prior to actual execution of the test on the tester. Resimulation has the advantage in that it can be performed in parallel to the fabrication of the physical integrated circuit device to be tested so that the test will be ready and “bug”-free when the physical embodiment of the integrated circuit device is available for testing on the tester. Resimulation uses a resimulation tool, which can use the same or a different simulator as that used to generate the test itself, that imports a tester-specific library that will generate the stimuli and receive simulated responses according to an ATE specific testbench that simulates/emulates the particular tester that will actually test the physical integrated circuit device.
Resimulation, or “virtual testing”, describes a software simulation of ATE testing an IC device. A virtual test typically has two main parts: the tester simulation (also referred to herein as “testbench”), and the integrated circuit device simulation. The testbench simulates or emulates the ATE, sending stimulus to, and receiving expected results from, the simulated integrated circuit device. The integrated circuit device simulation emulates the integrated circuit device being designed and/or tested based on the integrated circuit design generated during the design process.
Generally, the purpose of virtual testing is to debug the ATE test before silicon is physically available. This implies a “potentially flawed test, good design, good chip” approach. Sometimes virtual testing is also used to detect design flaws before expensive masks and first silicon are produced (corresponding to a “good test, bad design, good chip” approach).
It will be appreciated that a test really has two purposes: (1) pass good parts, and (2) fail bad parts. Current test development heavily favors only the first purpose of the test.
Resimulation allows verification of test prior to actual execution of the test on a tester. However, a test is only as good as the test coverage it provides. Test coverage is typically discussed in terms of “faults” and “defects”. A “defect” is a physical flaw on the integrated circuit that may be the result of poor design (e.g., missing links), poor fabrication (e.g., malformed vias or solder connections), or external events (e.g., particle contamination, change in environment such as a change in temperature that destroys all or a portion of the device). A “fault” is a model of a problem (e.g., a bit is stuck in a high or low state, or the operating current of the device is above a pre-defined threshold). For example, a stuck-at “fault” may indicate that a link of a transistor is broken, whereas the “defect” that caused the fault may be that the metal lines that fabricate the transistor were laid down incorrectly.
Test development is faced with two practical issues, among others. The first is that faults are more easily identifiable and translatable into a structural or functional test than actual defects. The second is that fabrication of integrated circuit devices is expensive and time-consuming. Therefore, test development tends to be focused on detecting identifiable faults and passing good parts if they do not exhibit the faults. In the test development environment, these goals often translate to the development of a test that heavily favors not failing good parts. The result of the test development process is that the test will not fail good parts. However, in meeting these criteria, the second purpose of test, namely, verifying that the test does not pass bad parts, is frequently overlooked.
In addition, because the test development process favors fault modeling (or detection of symptoms of defects rather than the defect itself), the test may actually miss detection of the defect itself, and falsely pass a defective part. What is needed, therefore, is a technique for verifying that that a test fails parts with actual defects rather than merely detecting the symptoms of defects through fault detection.
Accordingly, the invention allows simulation of the integrated circuit device as if it had known defects, rather than merely fault modeling the device, and verifies that the test actually catches the defects.